PWA Night Conference 2020
https://gyazo.com/05efcb8684b6333c685eaf10bb925e4f
https://www.youtube.com/watch?v=Xlj4Euf6FgA
Edge of the web（基調講演）
結局 PWAは来るの？来ないの？
2015年から言葉自体は出てた
従来のWebと違うのでは？という印象をあたえた
フレームワーク（名前付け）みたいな立ち位置
Webの歴史における１つのポイント
決していまやってるものを辞めて、PWAをつくるのはやめよう
今あるものを進化していこう
プログレッシブがその部分
Forget about PWA. Just build a "website" website
これは入れるべきかどうか、という判断をしよう
ホーム画面にアプリを追加できるのはすごい
PCだとブックマークで探れるがモバイルは大変
モバイルの体験が向上する
Progressive Wev Apps in the Microsoft Store
Bingから収集できたらアプリサイトに載せてもらえる
Trusted Web Activites
Webビューをつかっても実現できなかったことが可能になる
Google Play Storeに載せられる
コンバージョンレートが3倍
ログイン率3倍
レーティング4.1
規約はどうなるの？
Androidアプリの規約にならう必要がある
ストアで落としたら手数料などはAndroidにならう
CLIツール
TWA化への変換ツール
What's Next ?
Webに先進的な技術を持ち込もう
危険だけどちゃんと扱えればパワフル
Origin Trials
ブラウザベンダーごとに先行している技術
差異をどうカバーするか？
申請してもらう、ホワイトリストを発行してもらう
使ったらフィードバックください
Badging API
Shortcuts
アプリのコンテキストメニュー
web app manifest
Web Share
自分で好きなアプリを選ぶ
Web Share Target
逆にインテントを送ってきたときに受け取る
電話番号でログインする仕組み
OTPの手間を自動化する
Apple側のautocomplete="one-time-code"の実現 Clipboard API(image)
クリップボードのコピー
画像処理も進んでいる
漏洩を防ぐためにパーミッションを得るようにする
プラットフォームがもってるアドレス帳をつかう
ユーザーに渡したいアドレスを送ってそれを見れる
ローカルファイルの読み書きをする
デバイスと公開鍵暗号を組み合わす
2要素認証の実現
指紋認証もできる
サーバー側も含めるの若干複雑め
すべてのブラウザでサポート
What's coming next ?
２つの流れがある
Privacy Aware Web
HTMLにあるサブリソース（img, JS, CSS）を取りに行ってダウンロード
同じリソースじゃないところにあるソース（3rd Party）
Cookieでは情報がトラッキングされやすい
制限する動きがある
iframeでembed（ウィジェット：地図、動画）
ソーシャルログイン
送られるケースと送られないケース
代替案は考えているが。。。
準備はしっかりしてほしい
Mini apps エコシステム
基本的に使われるアプリ
アプリの中にWebアプリを入れる
標準化しようという動き
Gojekも宣言している
スーパーアプリを目指す宣言
KDDI
Google
まとめ
PWAはブランディング用語。Webを信じろ
新しい機能が提供され始めている
プライバシー注意、Mini appsの存在
Webでできる体験を考える会（Tech）
いろんなWeb APIを触ってみる
使ったこと無い人でもわかりやすく
使えるひとは発展していく
鳴るもの・動くものAPI
それぞれのNodeをコネクトしていく
BufferSourceNode
GainNode
AnlyzerNode
getByteTimeDomainData
GLSL
mixRatio
postprocessing
体験について考える
アプリと違ったメリット
すぐ遊べる
インスタント性
シェアのしやすさ
自分の家でできない部分を体験したい
MIDI通信をBlueToothで受け取る
TypeScript感覚でwasmがかける
WebWorker
重い処理をメインスレッドから外して別スレッドに移す技術
Transferable Object
postMessageをWorkerに送る
クライアント側は空になる
速さ比較
900ms => 1msかからなくなる
表現・体験について考える
プライベートを守りたい
すべてローカルで行えるようにしたい
暗号化
ImageMagick
FFMPEG
Web Crypto API
Fileの暗号化
アプリのように通知が出せる仕組み
Service Worker
通知の許可とTokenの取得
固有のToken取得
通知許可のだめな例
入ってすぐ取ろうとするやつ
ブロックされるとドメインでブロックされちゃう
体験を考える
スマートフォンはオンラインでセンサーがある
データメッセージ
ServiceWorker内で処理
通知出さなくても動く
fetchAPIが動く
Botnetのような振る舞いができる
DDOS攻撃
IP変わってもよく変わるのでは？
1日で使用するIPは1人で2.8個
日経電子版のモバイル/PC版統合と今後の取り組み（Biz & Global） 有料会員数が約70万人に
2019/10トップ画面のリニューアル
モバイルとPCの統合
なぜ統合したのか？
モバイル版とPC版の概要
PC
モノリシックアーキテクチャ
middlewareでリクエスト分散
キャッシュのコントロール
モバイル
2017年11月に刷新
全面リニューアルと一部統合
PWA化、パフォーマンスの大幅な改善
V2アーキテクチャ
各サービスのルーティングの役割
microservicesアーキテクチャ
全体構成
PC版とv2が共存
リクエストURLとユーザーエージェントで処理する
抱える課題
1. 開発チームの分断
リソースの分散
２つの実装をしなければならない
仕様をつたえるプロマネも２つ管理する
業務知識の分散
仕様書やドキュメントの管理が別
ノウハウがたまりづらい
2. PC版のパフォーマンス低下
10年間近くの運用
抜本的な改善は難易度が高い
3. デザインと機能の一貫性
カラースキームやコンポーネントの統一ができていない
いかに取り組むか
解決の理想形は？
Fastly + microservicesの構成
パフォーマンス
生産性高い開発
一貫性のある機能・デザイン
統合プロジェクト発足
2019/3
トップ画面の統合をやろう
今後を見据えたアーキテクチャへ
PCがFastlyを経由する
統合後にスムーズにPCからのアクセスを振り分けられるように
PCのための運用が続いてしまう
生産性を高める技術剪定
SSRをする
クライアントもサーバーもPure JSで開発する
技術スタックも変えていく
サーバー
共通ロジックも徐々に書き換え
JSXでデータの受け渡しが用意に
クライアント
追加ライブラリが不要
レンダリングロジックの見通しがよくなる
Workboxの導入
Service Workerを今まで素で書いていた
技術棚卸しと剪定、刷新
統合後のリリース後
パフォーマンスが上がらない
同一ドメインに統合版とPC版のためにキャッシュ戦略を練り直す
リリースはゴールではなくスタート
トップ画面の統合版リリースの取り組み
パフォーマンスのモニタリング
本番環境の計測
パフォーマンスバジェットを満たさない場合はアラートを流す
開発フローにもとづくもの
pushしたものマージしたもののイベントをフックにする
開発ブランチ、featreブランチを観測
地道なパフォーマンスチューニング
Resource HintやScriptへのasync/deferが付与されているか？
不要なリソース読み込みはないか？
ファーストビューに不要な画像がないか？
Service Workerを使った記事のprecache戦略の見直し
投機的なものは失敗することがある
上から順番に読んでくれるわけではない
キャッシュさせたものを高める施策
どの記事がどれくらい読まれているのか
prechaceに読まれていく
ユーザーが読むのではないか、というものをプリキャッシュ
リリース後の取り組みと今後の展望
ユーザー体験を高める施策や技術を取り組んでいきたい
既存機能の取捨選択は定量データとユーザ調査を基にUX担当者がリード
Why PWA should be on strategy map for eCommerce companies in 2020.（Biz & Global） 2017年からの開発
Servicde Workerの開発から8年
2012からスタート
Chromeが導入
2015にPWAに
Vue Storefront 1.0
PWAとは
信頼性
高速
ユーザへの価値提供・エンゲージメント
PWAはネイティブとWebを結びつけるもの
Web上に存在していないといけない
Webエクスペリエンスの理解が必要
購入へのきっかけが得られる
コミュニティ
6000GitHubスター
2500人のSlackメンバー
25カ国
50ものオフィシャルサポーター
オンライン・オフラインで様々なイベント
モバイルトラフィックの増加
アジアでは顕著
モバイルをやめてデスクトップに戻るのは愚か
デスクトップを見たことがない人もでてきた
eコマース売上が75%
モバイルで締める時間
時間を多くしめてもそこにお金を落とすわけではない
パフォーマンス、ユーザビリティがひどい
ロードされるのをまっていたら離脱してしまう
PWAはその応急処置
ネイティブのようにも使える
全画面表示
プッシュ通知はブロックするのでアプリ内通知をすべき
オフィラインモードが実装されている場合
接続が不安定でも
キャッシュでそのような不具合に気づかない体験ができる
UX
ページロードの速度問題
高速なWebサイトでもUIとUXがわるいとよくない
親指ルール
親指が届くエリアの割合を把握
片手でクリックしたいものを置く
下部ナビゲーションはクリックしやすい
左上のナビゲーションはなくした
ストーリー
Instagramみたいなやつ
ホームスクリーンで伝える
ビジュアルサーチ
STAPLES
画像から探す
実店舗でのB2Bセグメントに対して行う
ローカライズ
キオスクのように発売場所を把握できるようにする
ロイヤルティポイント
顧客の特別価値に合わせる
botチャット
eコマースでは今後も成長しそう
時間を節約してサービス自体のコストを削減
カスタマーサービスが必要じゃなくなる
AIによる自動化された回答
チェックアウト
カゴ落ちが多い場合
異なるアニメーションで引きるけるためのことを考える
チェックアウト自体を用意にする
12クリックしないといけないサイトも会った
支払いにだけクリックを限定することを推奨
3クリックで支払いができるように
チェックアウト後にメール送信
支払いサービスとの連動
Klarna
Stripe
Paypal
ローカル支払いとの統合
支払い
クレジットカード情報の入力が怖い
できるかぎりブラウザ内でワンクリック決済ができりょうに
高速
トップページにAMP
デザイン制限があるので実用意は足りない
ユースケースはいくつかある
PWAはSEOフレンドリー
ユーザーの体験速度に影響
オフラインブラウジング
オフラインでもカートに追加してチェックアウトまですすめられる
支払い時に同期
製品の在庫とチェック
問題なければ完了
フロント自体は変更なし
新しいモジュールを追加するだけ
ボイスコマンドで購入できるように準備できている
アナリティクス
タグマネージャーから各種ツールに
ウェブサイトのトラフィックを増やしてWebのユーザー動線を増やしてしていく
PWA Examples
LANCOME
コンバージョンを17%増加
OLX
エンゲージメントは250%増加した
直帰率が80%下がった
Alibaba
PWA＋Vue.jsを市場にだした最初のサイト
モバイルｈ76%増加
ホーム画面追加後のインタラクションが4倍
iOSとAndroidで多くの月間アクティブユーザー
AliExpress
新しいユーザーコンバージションレートが104%増加
Storefront UI
UIライブラリ
他のeコマースAPIやフロントエンドや統合できる
開発
H2O
picotls
quicly
IETF
プロトコルの標準化団体
HTTP/2でヒットした後にHTTP/3で渡す
レスポンスタイム短縮
500ms下がると売上はどれくらい上がるか〜という指標
クリック率についても言及
表示速度は売上に影響
ロード時間はバンド幅に比例しない
5Mbpsでも10Mbpsでも大きく変わらない
240msでロード4秒
20msはロード1秒
問題
通信に多重性がない
次の通信がくるまでの間待つ
複数のTCPでも限界はある
並列転送したら速度があがるのでは？
効果があったので標準化開始
2015に標準化完了
HTTP/2とは
TCP上でのバイナリプロトコル
複数のストリームを使って並列転送
フレームを組み合わせてHTTPを表現
stream IDや型、サイズが有る
HEADERS, DATA
HTTPヘッダ圧縮
優先度制御
CSSやJSのどっちを流すか
プッシュ
プロトコルの剪定
運用の切り替えについて
対応プロトコルを送信する
サーバーが決定して返信する
普及
全体の6割はHTTP/2で配信
TCP接続数は徐々に減ってきている
複数のサイトからダウンロードするので1にはならない
実際速いのか？
ベンチマーク
Chrome, Firefox, Safari
ページロードまでの時間
初期描画での差がでてる
優先制御ができている・できていないサイトがある
7割の人がHTTP/2にして早くなった。1割くらいで遅くなった人もいる
しかし3割は早くなって遅くなった人もいる
ネットワーク環境によるので差が出る
3Gの場合はHTTP/2は遅くなる
再送制御と輻輳制御の仕方で差が出る
ブラウザでのマトリクス比較
ないとHTTP/2が速い
あるとHTTP/2が遅いこともある
ブラウザごとで差がある
結論
ネットワークの利用効率は向上
パケットロスには弱い
優先度制御の起因
輻輳制御のアルゴリズムをちゃんとやる
1RTTに減らせるように
再送・輻輳制御の改善が困難
writeしたからといってすぐ届くとは限らない
遅延の発生
すぐに必要なデータが届けられない
攻撃耐性がない
TCPの硬直化
通信パターンを変えられない
機能追加・テストに時間がかかる
OSの一部のため
QUIC
Google QUIC (2012)
TLS, TCP, HTTP/2でやっていたことの置き換え
IETF QUIC
HTTP/3とTLSが上に乗る
ハンドシェイクをもってくる
多重化を請け負う
遅延が減って更新順序が増える
暗号化なので攻撃耐性あり
効果
インド
検索改善10%
YouTubeの動き固まる20%改善
ユーザーの接続が悪いときほど影響あり
HTTP/3はその上で動くプロトコル
HTTP/2の優先度制御問題
ブラウザごとで異なる
サーバーですべて請け負うのはしんどい
再設計がスタート 2019/7
優先度指定
拡張性確保
HTTPバージョンに依存しない
プロトコル選択
ALPNだけでは無理
初回は1 or 2で接続
サーバがalt-svcヘッダを送信
h3に対応しているのが判明したので送信
HTTP/3の効果
応答性の向上
再接続にかかる時間がゼロ
通信品質の向上
安定性など
ハンドオーバー
場所によってとぎれないユーザー体験
スクリプトからの優先度制御ができるかも？
対応状況
実装自体は多数存在
開発版が対応
HTTPの意味論とプロトコルの分割
レスポンスから判定
通信のやりかたはいろいろ
HTTP/3利用ためのAPI
コードの変更の必要はない
バージョンが非依存
ライブラリが最適なバージョンを自動選択
低水準なライブラリは意識する必要がある
どんな流れがあるか
HTTPとリアルタイム系プロトコルの融合
QUIC上でUDP的なことができる
応答性が重要なもの
用途：動画配信、ゲームなど
PWAとSEOは概念的にはそんなに関係ない
SEOのリスクを学んでビジネスを毀損しないようにしましょう
Google botにインデックスされること
botにクロールされること
sitemapや内部リンクを貼るなどで頑張る
非同期でとってきたものにリンクがあると問題は別
Facebook OGPやTwitter Card
SEO文脈で語られる
構造化データ
検索結果の表示のリッチさ
動画データ
SPAにおけるSEO課題
なぜ生じるか？
ブラウザを経由して
HTMLやJSを返す
JSがコンテンツを描画する
この部分で問題がある
基本的に情報がない
<div id="root">
課題
1. タイムアウト
リクエストに時間がかかるとインデックスされない
中途半端だと打ち切られる
何秒までまつ？
Fetch as Google
Search Consoleからどう見えてるかの確認
約５秒まてる
実際のGoogleインデックスの表示
約２０秒まてる
あくまでも目安
John Mueller曰く
5秒がいいターゲットだよ
2. メタ情報はサーバから返す時点でHTMLに含まれるべき
サーバーから帰ってくる時点でHTMLに含まれてないと解釈してくれない
すぐにインデックスされるのではなく
Render Queueに処理が移譲される
1週間かかることもある
コンテンツ更新が頻繁なサイトは問題になる
インデックスの遅延自体はChromeが今後改善してくれそう
Chromeと同じバージョンでレンダリングするに
心配ならFetch as Gooleで確認してみよう
どんな解決策があるか
1. メタ情報だけSSR
ミニマム対応
botかどうかで返すリクエストを変える
botじゃないとJSを返す
prerender.io に返す
キャッシュされているかどうかの判定
2018年くらいにGoogleが提唱
クローキング
botとユーザーに違うコンテンツを返すとペナルティがあるが
同一であれば多分大丈夫…？
信頼できるソリューション
タイムアウトしてもキャッシュがある
最終的にHTMLを返す
ログインユーザに見せる
ユーザカスタマイズのレコメンドを出す
サーバー側でJSを実行してHTMLを返す
注意点
SSGでもSSRでもタイムアウトは存在する
要求パターンごとの解決策の選び方
これで良いというものはない
社内の技術リソースなどと相談すべし
考えること
1. 頻繁に更新される、すぐインデックスしてほしいか？
ダイナミックレンダリングやろう
仮説
scriptタグがあるかどうか？
真ならSSRやSSGでも心配
2. SSG or SSRかSPAか
メリデメ
SSG or SSR
表示速度はやくなる
First Meaningful Paint
SEO対策にこれ以外の設定が不要
開発難易度上がる
ブラウザ上にしか存在しないオブジェクトや使うライブラリが対応しないとコケる
hydrationがうまく行かないバグ
SPA
開発が比較すると気にすることが減って楽
FMPの向上が頭打ち
3. SSRにするかSSGにするか
大体はSSGのほうが良いかも
難易度が低い
レンダリングサーバーのスケーラビリティを考えなくても良い
SEOしたいページ => ユーザー個人の情報などを動的に生成するものではないから要求的に問題ない
SSRがベターな例
SEOページが動的なもの
ユーザー投稿のブログサイト
リクエストに応じてSSRしてCDNキャッシュさせるのがよさそう ケーススタディ
とあるECサイト
Next.jsをつかったSSG
FMPが速いのでユーザー体験もプラス
そこまで商品ラインナップが増えそうでもない
インデックス速度も重要ではない
一部のライブラリのSSRの設定がめんどくさかっただけでSPAと比べてそこまで大変じゃない
Next.jsのエコシステムに乗っかれる
Don't be evilを信じろ
Taking your web app offline (in a good sense)（Biz & Global）
Webの問題
接続ステータスに依存
JSは豊富なUIや複雑なアプリ駆動のために発明されたものではない
解決法
キャッシュ
HTTP Cache
オフライン対応には向いてない
AppCache
インストール時
SPAの結果は予測できない
Chromeアプリはベンダー固有のため機能しない
フレームワークも不要に思えてきた
NativeScript, React Native
予測可能なキャッシュが使えてインストールできてWeb標準に準拠している必要があったから
PWAの定義について話し合いたい
PWAはどこでもネイティブのように動く
オフラインについて
ネイティブアプリケーションのものを見てそれと同じ用に実装する
インストール後に利用可能になる
オフラインでも定期的にアクセスできる
ランタイムの再利用は慎重に保存する
API, CDN
接続障害はUX影響がない
最新のデータであるべき
オフライン時でもハードウェア機能にアクセスできるように
これらにWebとのトレードオフはない
App Shell について
アセットの定義
キャッシュを配置
ネットワークがキャッシュを提供
最新のものを追加して古いものを削除
すべてのワークロードはイベントリスナーにラップされる
ファイルにキャシュ
キャッシュバージョンを管理
最新のものに更新
キャッシュ管理のイベントで考慮する事故とは多い
ユーザーが何を見逃してるかがわからない
考慮・管理すべきバージョンは大量にある
npm i -D workbox-build
workbox-build.js
config
workbox-service-worker.js
importScripts()
workbox.precaching.precacheAndoRoute
ビルドステップをメインのビルドフローに入れる
アプリケーションシェルの準備ができる
もはや手動でSW.js管理するのはしんどくない？
必要に応じで独自の設定やプラグインを作成しよう
オフラインのアクションとデータ
One-off event for offline => online
タブが閉じられたときもイベントは送信される
swRegistration.sync.register('XXXXX')
if (event.tag === XXXX) event.waitUtil( /* DO useful things... */ );
失敗した場合は再度処理する必要がある
code:workbox-service-worker.js
new wrokbox.backgroundSYnc.Plugin("XXXX", {
maxRetentionTime: 24 * 60
})
アプリケーションの更新について
Periodic background-sync
ブラウザにおけるクーロン
オフラインのみで機能
ネットワーク、バッテリー、CPUリソースが浪費されない
Workboxではモジュールがないからコードの記述は要る
ユーザのニーズに焦点を当てて良い施策を打っていきましょう
現在のMicrosoft Edge
モバイル版もリリース
iOS : webkit（WebCore + JavaScriptCore）
プラットフォーム版も対応
Linuxものちのち
入手方法
ダウンロード
Windows Update
4/1移行にアップデート
個人事業者のは３末まで
組織のものは自動更新されない
自動更新されるようになるのはまだ決まってない
Chroniumと以前のレガシーEdgeが混在する世界
レガシーEdge
UWP
Chrome寄りの実装
IEへの後方互換なし
Win10移行のみ提供
新Edge
Win32
Internet Explorerモード搭載
スパルタンProjectというコードネーム
どうしてもIEじゃないと動かないサイトだけ登録
Webスタンダードに足並み揃えた
WindowsにおけるPWA
以前はUWPでラップされたものをインストール
現在は従来の方法とEdgeメニューから直接インストールできる
Windows Web Applications Host
デスクトップアプリをつくる思想はWin10からあった
ホストされているWebサイトをネイティブのガワでラップする
WinRT（API）による機能
ブラウザからはダウンロードできない
PWAのインタラクション
ピン留め、スタートメニュー
インストール・アンインストール
タスクマネージャ、タスクスイッチャーはまだ未対応
ブラウザタスクマネージャでタブごとのプロセスが見える
キャッシュはいくらでも入る
ミニマルUIの指定
戻るボタン、検索、印刷ができる
継承認証
ブラウザにログインしたユーザーは自動的に認証
PWA開発者向け
開発中
通知
アプリが閉じても通知する
タスクバーへのバッチ通知
ジャンプリスト
認証活用
MS Graph APIを
インストール体験
ロード画面（白い画面を取り除ける）
取り組み
セルフパブリッシング
Microsoft Storeの開発者アカウント
パッケージングしてアプリケーションを後悔
自動インデックス
BingがWeb上のPWAを検出してレビューしてストア表示 UMPにラップされたPWA
検証はしっかりしよう（中の人談）
デベロッパーセンターの分析
アプリ内課金
URLを入れたらPWA化するソースをダウンロードできる
コマンドプロンプトでアップするとローカルインストールできる